                                                                     
                                                                     
                                                                     
                                             
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>
-=SOEN 6441 - Documentation Phase1=- </title>
<meta name="generator" content="TextMate http://macromates.com/">
<meta name="author" content="Buthainah Aldosary">
<link rel="stylesheet" type="text/css" href="style.css">
<!-- Date: 2013-05-15 -->
</head>
<body>
<div align="center">
	<h1>
	SOEN 6441- 1 2013 Collaborative Email Client </h1>
	<br>
	<br>
	<table border="1">
	<tr>
		<th>
			 Name
		</th>
		<th>
			 ID
		</th>
	</tr>
	<tr>
		<td>
			 Buthainah Aldosary
		</td>
		<td>
			 6302459
		</td>
	</tr>
	<tr>
		<td>
			 Musab M Mirza
		</td>
		<td>
			 6367216
		</td>
	</tr>
	<tr>
		<td>
			 Sukhjinder K. Narula
		</td>
		<td>
			 5285348
		</td>
	</tr>
	</table>
	<p>
		<b>
		Due Date: June 6, 2013 </b>
	</p>
	<p>
		<b>
		Version 2.0 </b>
	</p>
</div>
<h2>
Introduction </h2>
<p>
	 This design document outlines the architectural and component design of the Collaborative Email Client system using textual descriptions and supporting diagrams. The functional requirements are listed, architectural design, additional classes since phase 1, interesting classes and tests as well as some software quality measurements.
</p>
<h2>
Functional Requirements </h2>
<p>
	 The functional requirements for phase 2 of the project include:
</p>
<ul>
	<li>
	Email Templates: For the templates, our system supports system and user defined tokens. The system-defined tokens include:
	<ul>
		<li>
		To: To address for the current email. </li>
		<li>
		From: The logged in user’s username. </li>
		<li>
		Time: Current time of the system in the format of: 1:54 PM. </li>
		<li>
		Date: Current date of the system in the format of 12-12-2013. </li>
	</ul>
	</li>
	<li>
	Email Search: Allows the user to specify the To, From, Subject, and Body fields and applies and aggregate operation search query on emails in all folders and displays the results. </li>
	<li>
	Email Filters that move emails into a specified folder that match search criteria periodically: The user can add/ edit/ delete/ apply filters to emails and move the results to a specified folder every 10 minutes. </li>
	<li>
	Create meetings with other email attendees and send an email informing them: The user can create a meeting a specify the recipients in the To field. Upon creating the meeting, an email is sent to each recipient with a custom body in the following format: </li>
	<p style="color:blue;">
		 Hello (to), <br>
		 A meeting was created (or updated) by (from) which includes you. Here are the details: <br>
		 Start time: (..) <br>
		 End time: (..) <br>
		 Topic: (..) <br>
		 Description:(..) <br>
		 Other attendees: (..) <br>
		 Thank you. <br>
	</p>
	<li>
	Edit a meeting. </li>
	<li>
	Delete a meeting. </li>
</ul>
<h2>
Challenges and Solutions </h2>
<p>
	 Phase 2 put us in the ring with some interesting new challenges. After multiple meetings and discussions, we were able to tackle them. Limited time was the major reason for these tasks to become relatively difficult.
</p>
<strong>
Templating with user and system tokens </strong>
<p>
	 Tokenization and dynamic templating was challenging and fun. We implemented a system where the user could define his own token value combinations and use them while composing emails. The tokens would be dynamically replaced at the time when the email is sent.
</p>
<p>
	 Along with this, there were 4 predefined system tokens (to, from, date, time). These tokens could not be overridden by the user. System defined tokens could be added into ths conig.properties file and then implemented. Any one of them could be commented off to disable
</p>
<p>
	 To implement this functionality, the TemplateCompiler class was created. Given a hashmap of token/value combinations, it would compile a String (usually the email body) and replace the token occurances. No external script was used for this purpose and it was achieved using simple regular expressions.
</p>
<strong>
Automated meeting emails </strong>
<p>
	 A user is also given the ability to create meetings and up creation/update, emails are sent out to all attendees. This objective was accomplished in the meetings class.
</p>
<p>
	 Interesting challenges in this task were the validations when creating/updating a meeting. We implemented the following main checks for meeting creations:
	<ul>
		<li>
		Start date could not be greater than end date </li>
		<li>
		The new meeting interval should never overlab with any other existing meetings </li>
	</ul>
</p>
<strong>
Filters and search </strong>
<p>
	 A user can define custom filters in an AND combination with the following fields:
	<ul>
		<li>
		To </li>
		<li>
		From </li>
		<li>
		Subject </li>
		<li>
		Body </li>
	</ul>
	 The above fields were also the criteria while performing search. The filters would run after every 15 minutes and move the emails in their corresponding (defined) folders. The MeetingsController communicates the model to return a list of Email objects and then updates their parent folders in the DAO and domain models.
</p>
<h2>
Separation of Concerns </h2>
<p>
	 We strictly followed MVC and modular programminc practices in this project to keep things as separate as possible. The model and view classes as 100% separate and their is no code leakage between them. The Controller class knows the Model and View and acts as a mediator. The persistent (SQLite) is completely independent and can be easily replaced. There is a uni-directional communication from Model to DAO.
</p>
<div align="center">
	<img src="img/mvc.jpg">
</div>

<h2>
Code Quality and Analysis </h2>
<p>
	 Using CodePro tools from Google, we have fixed many bugs and improved our code quality. We have also used FindBugs to help us in static inline code analysis. Our analysis suggests that the project is in good health. The only class that needs a bit of refactoring is the User.java model class.
</p>
</p>
 Code quality reports are below:
</p>
<p>
<strong><a href="_dependency_analysis.html">Dependency analysis</a></strong><br>
<strong><a href="_metrics.html">Software metrics</a></strong>
</p>
<h2>
Major Class Addition </h2>
<p>
	 The following classes have been added in addition to phase 1 classes:
</p>
<h3>
View Package </h3>
<ul>
	<li>
	Edit Filter Panel. </li>
	<li>
	Edit Meeting View </li>
	<li>
	Edit Template Panel. </li>
	<li>
	Filters View. </li>
	<li>
	Icons Manager. </li>
	<li>
	Meeting Navigation View. </li>
	<li>
	Meetings View. </li>
	<li>
	New Meeting View. </li>
	<li>
	Preview Meeting View. </li>
	<li>
	Search View. </li>
	<li>
	Token View. </li>
	<li>
	View Helpers. </li>
</ul>
<h3>
Controller Package </h3>
<ul>
	<li>
	Edit Filter Controller. </li>
	<li>
	Edit Meeting Controller. </li>
	<li>
	Edit Template Controller. </li>
	<li>
	Filters View Controller. </li>
	<li>
	Meetings Controller. </li>
	<li>
	New Meeting Controller. </li>
	<li>
	Search Controller. </li>
	<li>
	Template View Controller. </li>
	<li>
	Token View Controller. </li>
</ul>
<h3>
Model Package </h3>
<ul>
	<li>
	Filter </li>
	<li>
	Filter Builder. </li>
	<li>
	Meeting. </li>
	<li>
	Meeting Builder. </li>
	<li>
	Search Email. </li>
	<li>
	System Tokens. </li>
	<li>
	Template </li>
	<li>
	Template Compiler. </li>
	<li>
	Token </li>
</ul>
<h3>
Test Package </h3>
<ul>
	<li>
	Test Filter Builder </li>
	<li>
	Test Meeting Builder. </li>
	<li>
	Test Suite Part 2. </li>
	<li>
	Test Template Compiler. </li>
	<li>
	Test User Filters. </li>
	<li>
	Test User Folders and Emails. </li>
	<li>
	Test User Meetings. </li>
	<li>
	Test User Templates. </li>
	<li>
	Test User Tokens. </li>
</ul>
<h3>
Dao Package </h3>
<ul>
	<li>
	Filter Dao. </li>
	<li>
	Filter SQL Dao. </li>
	<li>
	Meeting Dao. </li>
	<li>
	Meeting SQL Dao. </li>
	<li>
	Template Dao. </li>
	<li>
	Template SQL Dao. </li>
	<li>
	Token Dao. </li>
	<li>
	Token SQL Dao. </li>
</ul>
<h2>
Interesting Classes </h2>
<p>
	 Classes on interest that are worth pointing out are as follows:
</p>
<ul>
	<li>
	View Helpers Class: </li>
	<p>
		 The view helpers class is used to display message dialogs for errors, information, plain dialogs with specified messages and titles. This class is also used to dispose parent dialogs upon closing the child dialog.
	</p>
	<li>
	Template Compiler Class: </li>
	<p>
		 The template compiler class is used to parse a template body by replacing all token (system or user) occurrences with their values.
	</p>
	<li>
	Icon Manager Class: </li>
	<p>
		 The icon manager is a static class that is used when needed in views to get image icons with a specified path. This reduces clutter in view classes and increases information hiding.
	</p>
	<li>
	Meeting and Filter Builder Classes: </li>
	<p>
		 These classes apply the builder design pattern and are used to construct new Meetings and Filters. They were implemented because the constructors of these two classes have more than 3 parameters.
	</p>
</ul>
<h2>
Tests Coverage </h2>
<div align="center">
	<img src="img/test_coverage.png">
</div>
<p>
	 As previously stated in phase 1, our system has been tested using the JUnit 4 Framework for the Java Programming Language. EclEmma Java code coverage plug-in for eclipse was used to measure the percentage of code coverage. The total code coverage for unit tests is 38.8%. Some interesting test classes are:
</p>
<ol>
	<li>
	Test Template Compiler </li>
	<p>
		 In this test class, the system under test (SUT) is the TemplateCompiler. We have aimed to test three conditions:
	</p>
	<ul>
		<li>
		Testing with no tokens. </li>
		<li>
		Testing with valid tokens, valid body. </li>
		<li>
		Testing with invalid token specification in the body. </li>
	</ul>
	<li>
	Test Email Search </li>
	<p>
		 In this test class, the system under test (SUT) is the User. We have aimed to test the following conditions:
	</p>
	<ul>
		<li>
		Test email search with blank body. </li>
		<li>
		Test email search with blank from. </li>
		<li>
		Test email search with blank subject. </li>
		<li>
		Test email search with blank to. </li>
		<li>
		Test email search with null all fields. </li>
		<li>
		Test email search with null body. </li>
		<li>
		Test email search with null from. </li>
		<li>
		Test email search with null subject. </li>
		<li>
		Test email search with null to. </li>
		<li>
		Test email search for body field regular and Caps. </li>
		<li>
		Test email search for from field regular and Caps.. </li>
		<li>
		Test email search for subject field regular and Caps. </li>
		<li>
		Test email search for to field regular and Caps.. </li>
	</ul>
</ol>


<script type="text/javascript" src="http://code.jquery.com/jquery-1.9.1.min.js">
</script>
<script type="text/javascript" src="js/custom.js">
</script>
</body>
</html>